Toward 2000: The Cisco X.25 Development Strategy

This document outlines Cisco's X.25 development strategy over the next year. The aim of this strategy is to assist the evolution of X.25 networks. Knowledge of X.25 technology is assumed. For definitions of specific terminology, please refer to the Appendix.

There are two key assumptions behind this strategy: replacement of X.25 networks by alternative technology will only be applicable for particular organizations; X.25 will continue to be a significant technology through the year 2000 for a large number of organizations.

Co-existence of X.25 and internetworking technology is hence a requirement. Figure 1 shows how X.25 is positioned as a WAN transport within the enterprise model used for Cisco's Internetworking Operating System (IOS[tm]). It should also be noted that X.25 is an end-to-end protocol in its own right.

Figure 1: X.25 and the IOS

Cisco's X.25 development strategy is defined in three phases. In each phase, three major categories of requirements are addressed:

• Interoperability
• Performance and availability
• Scalability

This document provides an overview of X.25 networks as they exist today, describes the challenges in evolving these networks and outlines in detail Cisco's strategy in meeting those challenges.

X.25 Today

• Switches
• Hosts
• Terminals
• PADs
• Management systems

Investments in the above network elements must be leveraged and hence replacement of X.25 network is rarely possible.

In most enterprise networks, LANs have also been deployed as tactical responses to particular requirements. Currently, these LANs are isolated workgroup solutions. Figure 2 shows a typical network with its existing X.25 infrastructure and isolated LANs.

Figure 2: X.25 Networks and Isolated LANs

Evolution Driver (1) -- Client-Server

Evolution Driver (2) -- Bandwidth

In this situation, network replacement is not necessarily required, but there will be cases where the X.25 switches or services are incapable of supporting the bandwidths required. In these cases, a core network upgrade will be necessary, but at the same time support for legacy X.25 applications must be provided.

Challenges

• Interoperability: Critical for smooth evolution and to ensure the ability to change tacks as technology evolves.

• Performance and Availability: Essential for end-user satisfaction and cost control. In many cases, outages and poor response have a significant negative impact on the ability of an enterprise to meet its goals.

• Scalability: Important for successful deployment, operation, and management of the very large enterprise networks.

In more technical detail, the challenges of each area can be described as follows.

Interoperability

• DTE-DCE: Lower cost and higher performance access technology.
• DTE-DTE: Multiprotocol support and legacy host compatibility.
• PAD-DTE: Multiprotocol asynch remote node access to networks via PADs.

Performance and Availability

• DTE-DCE: Rapid failure detection and throughput on high-speed links
• DTE-DTE: Payload Compression and Update-only routing protocols

Scalability

Poor scalability turns a two-year project into a five-year project and ends with the key business benefits often being lost, or even worse, overwhelmed by the negative impacts of a slow roll-out and poor operational characteristics.

The key scalability issues are:

• DTE Operation: Routing over X.25 should be done optimally with minimal configuration, routing updates and hops across the network.

• DCE Operation: Switching of large numbers of X.25 connections over multiprotocol backbones must be done reliably and with minimal configuration in each switch.

• Management: Centralized and automated management is needed to assist the building of large networks.

Cisco X.25 Support

X.25 DTE Support

Management is provided through extensive debug facilities as well as the LAP-B and X.25 MIBs specified by RFC 1381 and RFC 1382.

Multiprotocol support with multiple virtual connections per protocol per destination is provided. In addition, TCP/IP Header Compression, as specified by RFC 1144, is also supported. By reducing headers from 40 octets to 5 octets through this feature, response time improvements of 30 percent have been measured.

X.25 DCE/Switch Support

Figure 3: X.25 Over TCP

X.25 PAD Support

As shown in Figure 4, the PAD function can be found on the following products:

• Communications server
• Protocol translator
• Router (Aux port)

Figure 4: PAD Support in the Cisco Product Line

ISO-CONS (CMNS) Support

Three-Phase Development Plan

The timetable for the phases is as follows:

Phase I: First half 1994
Phase II: Second half 1994
Phase III: First half 1995

The following chart (figure 5) provides an snapshot view of Cisco's X.25 three phase strategy. Following the graphic is a discussion of the key issues addressed within each of the three phases.

Figure 5: The Three-Phase X.25 Development Plan

Phase I

Interoperability

Three Cisco features which advance interoperability are:

• X.25 1988: This is supported including redirection and higher throughput classes. Interoperability with switches set to this mode is hence guaranteed.

• Dial-Up X.25: This allows a router to dial-up a synchronous connection to an X.25 network and provides advantages in term of low-cost access as well as backup to dedicated X.25 access lines or non-X.25 access lines.

• Management via PAD: This allows existing X.25 network console to configure routers by connecting to the router as if it were an X.25 host with PAD capability. This provides enhanced management functionality such as changes to IP addresses on the fly and IP independent monitoring of X.25 connectivity.

Performance and Availability

• Update Only Routing: This is already provided for IP and OSI through BGP IV, OSPF and IS-IS. Support for IPX and Appletalk is now added through E-IGRP and support for VINES is added through Sequenced RTP (VINES 5.5x). In addition, update only SAPs are supported through the Reliable SAP Update Protocol (RSUP).

• Virtual Interfaces (VI): This allows more flexible network design. Each VI is treated as an interface and each VC is assumed to act as a leased line. Functionality such as access lists and routing metrics configuration is not sacrificed when X.25 is used. For example, in figure 6, traffic from A to C can directed through D as the lowest cost path.

Figure 6: X.25 Virtual Interfaces

Scalability

• Increased VC Capability: TCP was rewritten for low processor overhead and hence now more than 1,000 VCs can be supported on a unit acting as an X.25 switch and supporting X.25 over TCP/IP (XOT).

• Simplified Configuration and Management: Through the use of global commands, X.25 map statements in many routers can be changed simultaneously. This significantly improves the ability of a single staff member to administer a very large network. Productivity enhancement through smaller change windows and reduced error incidence can also be expected.

Phase II

• Single VC operation
• Data compression
• B-channel access
• QLLC integration

Details on this release are as follows.

Interoperability

• ISDN B Channel (64K) Access: In many countries, B channel access often costs less than dedicated 48K access. Carriers are taking advantage of the lower transmission costs associated with ISDN access technology and passing these savings on to users. With B channel access, Cisco is the first major vendor to provide an integrated solution.

• Access Server: Cisco will be releasing an integrated switch/PAD/ router/translator which will substitute for standard PADs, but provide significantly greater evolution capability through support of full routing and multi-protocol asynch access, including SLIP, PPP and ARAP.

• QLLC: IBM FEPs run NPSI software to support SNA over X.25, otherwise known as QLLC. The installed QLLC base is enormous and Cisco's QLLC support will increase the evolution options. For example, as shown in figure 7, NPSI can be removed from front-ends and the number of front- ends can be reduced by using Cisco routers to terminate the X.25 lines and to convert QLLC to LLC. Similarly, remote sites with Token Rings can use the router as the QLLC gateway.

Figure 7: QLLC and Its Application

Performance and Availability

• Modulo 128 LAPB: This significantly improves throughput where the bandwidth-latency factor is very high by allowing a much larger window of packets to be transferred before receiving an acknowledgment. This is the case for 2 Mbit/sec lines and satellite links.

• T4 Timer: Fast failure detection is achieved by using LAPB Receive Ready (RR) packets as keepalives. If a timer expires, the access link is assumed to be down and rerouting starts to occur.

• Payload Compression: End-to-end throughput and latency is significantly improved through the use of compression. Compression ratios of greater than 4:1 are possible, but are dependent on traffic type and hence typical compression ratios are 1.7:1. In addition, compression can significantly reduce usage charges. Figure 8 shows a router compressing the payload of an X.25 data stream.

Figure 8: X.25 Payload Compression

Scalability

• RISC Processing: With the introduction of the 4500, Cisco has a platform which is optimized for the central site where it can perform the processor-intensive functions needed for X.25.

• RFC 1356: This replaces RFC 877 which defined the transport of IP and OSI in independent VCs. RFC 1356 enhances this with multiprotocol VCs and full standards support for non-IP protocols. Multiprotocol VCs improve scaling by reducing the number of VCs needed. Reduced usage charges can also be expected because there will be fewer VCs established. Figure 9 shows AppleTalk and Novell hosts sharing a single VC across an X.25 network.

Figure 9: RFC 1356 and Multiprotocol VCs

Phase III

• D-channel access
• Remote Node access
• AutoInstall
• Snapshot routing
• One-hop routing (NHRP)

Interoperability

• ISDN D-Channel Support: D-channel access tariffs are very low and indeed are often much cheaper than 9600 bit/s dedicated access. This is ideally suited to low volume applications where continuous connectivity or low transaction times are required. Simultaneous support of ISDN B channels will be possible.

• Remote Node via PADs: Remote Node technology is normally provided via Communications or Access Servers. In cases where a large investment in PADs has been made, there is a need to support SLIP, PPP and ARAP over X.25 using the existing PADs. As shown in figure 10, Cisco routers will provide support for IP, IPX AT over SLIP/PPP/ARA over X.25.

Figure 10: Remote Node via PADs

Performance and Availability

• AutoInstall: Simpler installation and replacement reduces the cost of ownership and can also reduce the downtime associated with equipment failures. A replacement box can be inserted and can have configurations automatically downloaded with the AutoInstall facility. No special router skills are required. Spare boxes can be kept on site or in depots without the need for highly skilled networking managers. This will reduce the Mean Time to Repair (MTTR) significantly.

• Snapshot Routing: This removes the need for permanent connections while still having the advantages of using dynamic routing. As shown in figure 11, a remote router connects to a central router and gets a snapshot of the central routing table, which it then advertises to remote users. There are two connection triggers; periodic connections and traffic-driven connections.

Figure 11: Snapshot Routing Over X.25

Scalability

• NHRP: This provides one-hop routing from router to router across an X.25 network. This results in optimum performance, lower usage charges and eliminates the full-mesh requirement. Optimum path selection is achieved through a multistage process shown in figure 12:

  1. Incoming packet from host
  2. NHRP request to core router
  3. NHRP request to remote router
  4. NHRP reply to core router
  5. NHRP reply to original router
  6. VC established to remote router

Figure 12: Next Hop Routing Protocol

• Scalable Switching: Where large numbers of X.25 switches are being replaced by core routers to allow migration to client/server technology with routing support, there is a need for scalable X.25 switching with hundreds of routers acting as switches. Centralized route selection is achieved through the multistage process shown in figure 13:

  1. Incoming call with X.121 address
  2. Look up central directory
  3. Directory response with IP address
  4. Route call to IP address
  5. Complete call

Figure 13: Scalable X.25 Switching

Summary

X.25 is one of many WAN technologies in which Cisco intends to maintain leadership. Furthermore we are committed to developing the broadest technology support for all significant WAN technologies, including Frame Relay, ATM, ISDN and SMDS.

We intend to maintain leadership by leveraging years of experience and by continuing partnership with successful customers. R&D investment which is focused on real customer requirements, is clearly a necessity.

All of Cisco's WAN developments fit under Cisco's IOS umbrella. The goal of Cisco's IOS is to provide each enterprise the opportunity to build a single network to support all requirements. Strong X.25 support is part of the goal to provide consistent enterprise-wide networking. Cisco IOS advantages are:

• Enterprise-wide services
• Minimum WAN costs
• Smooth evolution
• Common management
• Consistent support

Appendix: Terminology

Wide Area Network used to connect an enterprise. It can include X.25, Frame Relay, ISDN, ATM or simply leased lines.

X.25

CCITT (ITU) standard for interfacing to public packet switched networks.

XOT

X.25 over TCP standard defined by RFC 1613 which allows X.25 to be transported across an Internet backbone.

For more information on Cisco's X.25 products, please contact Morgan Littlewood, Product Manager WAN, at littlewo@cisco.com.

Copyright 1996 © Cisco Systems Inc.